Tests on 5800X + 3080Ti

Your chart got my interest, so I took some readings of my own before and with your PR and... holy shit with FPS limited, CPU usage was approximately halved.

So for me didn't make any difference when using unlimited FPS. But amazing reduction in CPU and GPU usage when limited.

Is this CPU usage now freed up so that players with low performance systems are now potentially going to get a much better FPS because that CPU time is now available to actually compute things, or no? I dunno just seems to good to be true because so many MTA players don't have good PCs so this change would be monumental for them.

I've done some further testing, with some high CPU load:

crun setTimer(function() for i=1, 10000 do getElementData(localPlayer, "a") end end, 50, 0)

CPU and FPS were the same with and without this PR when under heavy load, when FPS was limited. However when FPS was set to a max of 60, it remained 60 FPS with the PR, but was 50 FPS on standard. Though is it possible although FPS may say it's higher it might not be better in the sense that the 10 extra frames may have tiny gaps between them and so some could end up being unbalanced in terms of feeling of smoothness.

Is this CPU usage now freed up so that players with low performance systems are now potentially going to get a much better FPS because that CPU time is now available to actually compute things, or no?

Yes. The old limiter wasted CPU cycles in a busy-wait loop after finishing a frame. That didn’t steal time from MTA's or SA’s own logic/rendering, but it did keep one core artificially busy doing nothing.

TL;DR: I replaced a spinlock (Tight loop calling Sleep) with a mixed approach to not burn so many CPU cycles

Your chart got my interest, so I took some readings of my own before and with your PR and... holy shit with FPS limited, CPU usage was approximately halved.
FPS CPU GPU
Normal unlimited (197) 11% 34%
PR unlimited (197) 11% 29%
Normal limited 60 9.2% 25%
PR limited 60 4.7% 18%

It'd be nice to know CPU + GPU combo

It'd be nice to know CPU + GPU combo

i7-10700K + GTX 1070

My readings were based on a rough average of what task manager said.

Is this CPU usage now freed up so that players with low performance systems are now potentially going to get a much better FPS because that CPU time is now available to actually compute things, or no?

Short answer: kinda, but it's more about not wasting CPU cycles than giving you free performance.

Long answer:

The old frame limiter was genuinely awful (Sorry OG code dev). Look at this mess:

while (true) {
    double dSpare = dTargetTimeToUse - m_FrameRateTimer.Get();
    if (dSpare <= 0.0) break;
    if (dSpare >= 10.0)
        Sleep(1);  // Only sleep if >= 10ms left, otherwise just spin
}

So let's walk through what happened on a typical frame. You want 30fps (33.3ms), game renders in, let's say 4ms. Now you need to kill 29ms somehow to fit the frame target.

First it burns through 19ms calling Sleep(1) over and over... that's 19 separate system calls. Then when you're down to the last 9ms? It just sits there spinning the CPU, constantly checking m_FrameRateTimer.Get() in a tight loop until time runs out. This is the CPU burning I'm fixing.

Also, for lower FPS target, the more wasted cycles because you're waiting longer. 30fps wastes way more CPU than 144fps.

It's true that on lower end systems "render" time can be longer ms and it'd need to fill less, but the fact remains true for the remaining time.

The new approach is actually intelligent:

// Learn the sleep overhead, then sleep for most of the wait in ONE call
if (remaining_ms > sleep_overhead + 0.5) {
    Sleep(remaining_ms - learned_overhead);
}
// For medium waits, yield instead of spinning  
else if (remaining_ms > yield_overhead + 0.05) {
    Sleep(0);
}
// Only spin for the final microseconds where precision matters
if (still_need_to_wait) {
    if (remaining > 0.02ms) {
        for (int i = 0; i < 10; i++) _mm_pause();  // Batched pauses
    } else {
        _mm_pause();  // Ultra-tight final loop
    }
}

So, ONE bulk Sleep, then Sleep(0) for medium waits, and finally _mm_pause() for the last few microseconds.

One of the key insights is that it measures how long Sleep() actually takes on your machine and it adapts. Instead of guessing "Sleep(1) takes 1ms", it tracks the real overhead and somewhat compensates.

Plus it uses QueryPerformanceCounter for microsecond precision instead of that janky millisecond timer.

Will this give you +90 FPS? Nah. But it stops your CPU from pointlessly burning cycles just to wait around. The freed up CPU time goes back to the OS for other stuff like better multitasking, less heat, more headroom for background processes.

If you were already CPU bottlenecked somewhere else, this won't magically fix that. But if frame limiting was eating cycles for no reason, yeah those cycles are available now.

I dunno just seems to good to be true because so many MTA players don't have good PCs so this change would be monumental for them.

I get the skepticism but honestly this was just really bad code that got fixed.

Think about it: if you're running 30fps on a potato PC, the old limiter was literally doing 30+ unnecessary system calls per frame just to wait around, then spinning the CPU for whatever was left.

That's like 900+ wasted Sleep() calls per second plus constant busy-waiting IN A SECOND.

On weak hardware it actually matters more because every wasted cycle hurts.

The improvement scales with how bad your FPS cap is...

So yeah, players stuck at 30fps because their PC sucks will see the biggest benefit. Not necessarily higher FPS, but way less pointless CPU waste that was competing with the actual game.

On the other part, there is this issue with how MTA tried to frame-limit... It had two codepaths and I disabled one, with no real impact BUT the main menu rendering limit, which doesn't use the CTimer as the game is "technically" not using the timer until it's connected.

I need to find a proper way to fix the other codepath...

More benchmarks if you care, ran at 1600x900 windowed
CPU: Ryzen 7 7800X3D
GPU: RTX 5070

NOTE: I had to wait like 5 to 10 minutes before the CPU usage dropped on 1.6 release (before it was at least 10% usage all the time), meanwhile this didn't happen with the PR. More over this dropped my unlimited FPS from 550fps to 480fps.

No difference in FPS disabling the cap, but the CPU usage is noticeable smaller for the capped results.

That 10% constant usage you speak of is something I've seen before, it seems to be a random thing.

If this PR is complete I think you need to mark it as not a draft, so that it will get looked at.

If this PR is complete I think you need to mark it as not a draft, so that it will get looked at.

Still a draft as it has a huge BUT. The main menu don't get proper limitations.

That 10% constant usage you speak of is something I've seen before, it seems to be a random thing.

Probably MTA doing might and magic checks for it's own safety related to anticheat measures or release nitpicks... Can't tell really as I didn't really want to deep dive and risk a ban.

For a more fair comparison you can try:

1. Git clone and Build master: Save as baseline. Keep the commit hash for reference.
2. Apply patch (4385.diff): Rebuild & save as patched.
3. Run both under identical conditions: Same server, same map. I used Map Editor for ease of use.
4. Measure CPU usage: idle + load. I used System Informer for coarse graph plot.

5. Compare baseline vs patched: And see if it's improved. Must be relatively near to current measurements.

I've finished the relevant changes.
I added some goodies and TODOs that don't really harm and might need a little inspection for later refactors along the way.

FPS metrics

Tested idling in Ganton with no resources and no vehicles around. "stopall" basically.

Main Menu

Ingame

Test Request: @PlatinMTA @ArranTuna and anyone not mentioned that wants to help

New Features

VSync Frame Limiting

The game can now synchronize its frame rate with your monitor’s refresh rate.

• Enable: vsync = 1
• Disable: vsync = 0
• Default: 1 (enabled)

New CVar: vsync

• Purpose: Locks the frame rate to the monitor’s refresh rate when enabled.
• Default: 1

Frame Limiter

Frame rate limits are applied in this priority order:

1. Server Enforced – Hard cap set by the server
2. Client Enforced – Explicit cap set by the client
3. Client Preferred – Preferred cap via fps_limit CVar
4. VSync – Falls back to monitor refresh rate if no stricter cap applies

Rule: The lowest active limit always takes precedence.

API Functions

• setFPSLimit(limit) – server or client enforced (unchanged)
• fps_limit CVar – client preferred (unchanged)
• vsync CVar – enables/disables monitor sync (new)

Examples

Frame Limiter Examples

Possible later improvements to add:

• Settings toggle for vsync

Possible later improvements to add:

* Settings toggle for `vsync`

Would be quite useful and shouldn't be too hard to implement. That said, the average user likely isn't very familiar with CVARs or how to use them.

Possible later improvements to add:

• Settings toggle for vsync

Since you've added such a CVAR, it's your responsibility to add the corresponding setting in the menu. I think the PR is incomplete without it.

Added VSync option to settings:

Rebased branch to provide a clean linear history on top of latest master

Tested locally, compiles successfully, server runs normally, and all modified functionality works as expected... It feels done.

I've tested it.

Saves a lot of CPU when minimized. CPU usage is 1% instead of 4%.

Thanks @PerikiyoXD, this is huge. I've asked for an additional MTA team opinion and we'll be merging it now, so it can be tested before the release of 1.7